@dlobato What do you think?

I believe #443 already solves the problems mentioned on #428
This is a different feature, or Am I seeing this wrong?

This pull request is more elaborate and offers a guest customer to login as well (with a jwt token and so on). It requires the customer to provide some information about the order (and not just the order uuid) to confirm that it is indeed the guest who orders it.

The use case that I'm more concerned about is "changing payment after payment failure on guest checkout". So, as far as this is covered with this change I'm fine with it. I'd suggest to make authentication with guest users optional, showing only a limited view of orders as implemented in #443. This way we can keep the checkout process simple and still show the complete order to a guest user if she provides enough information to trust her.

Also, @lchrusciel stated: "According to orders endpoint, I would say, that we should stick as close as possible with the default implementation", and in my eyes this PR already moves a little bit away from it.

Co-dev for this PR here: So this PR does not fiddle around with payment or anything - this is just there to enable a guest to check on his order after a period of time with protected access through a guest-firewall.
I am sure one can extend on this to enable order modification for guest orders - and in my personal opinion failed payments and a subsequent change of the payment method should be handled before an order is created (e.g. PayPal, CC and other instant payments). For other payments, an order should be cancelled and reordered instead of changing the payment, what do you think?

This could be closed in favor of #443 which has been merged.

@lchrusciel just pinging you again to see this 🙂 🚀

@lchrusciel Still no update on this?